Add IPv6 support for Directories (still incomplete) - #3809

MY LLM WROTE:

During #3636's TCP-fallback testing, we reproduced the exact gap this PR aims to close. A server registering from a genuine (non-v4-mapped) IPv6 address appears in the server list with IP = 0.0.0.0.

The reproduction:

• Server registered from fd00::2 (with IPV6_V6ONLY=1, no dual-stack v4-mapping)
• Server appeared in the list with correct port/name/city but ip=0.0.0.0
• Root cause: CreateCLServerListMes / CreateCLRedServerListMes (protocol.cpp:2154, :2277) encode via HostAddr.InetAddr.toIPv4Address() — a hard 4-byte IPv4-only field. Qt's toIPv4Address() returns 0 for a true IPv6 address.

This confirms that TCP fallback (#3636) is necessary but not sufficient — even with reliable transport, the list's wire format itself can't currently describe an IPv6-only server. Your branch's protocol changes are the right lever; wanted to offer this concrete repro in case it helps the verification/test plan.

Edit: since the PR asks what's still missing, two more observations from reading the current diff. Both are "not yet done" rather than "wrong" — take or leave them for the eventual checklist.

1. MAX_LEN_IP_ADDRESS 15 → 39 also has a directory-side effect. We raised the client-side half of this in #1950 (comment) (old clients decode the list's string slot bound to 15 at protocol.cpp:2178, and GetStringFromStream rejects the entire message on overflow). The same guard sits on the registration path, read by the directory: protocol.cpp:1900 and :2020, the "server internal address" field of CLM_REGISTER_SERVER[_EX]. So if a server on this branch ever sends an IPv6 literal longer than 15 characters to a directory running a released version, the register message is discarded whole — silent total registration failure rather than a degraded listing.

The current diff avoids that, because ServerPublicIP6 is only passed when DirectoryAddress is itself IPv6, so an IPv4 directory still receives an IPv4 literal. But that invariant is implicit — nothing in the code states or enforces it, and it would be easy to lose in a later refactor. Might be worth pinning it down explicitly, and noting the upgrade ordering (directories before servers) in the release notes.

2. There's no --serverpublicip6 counterpart. The IPv4 path (serverlist.cpp:170-181) has a user override precisely because auto-detection is wrong behind NAT. The new v6 branch (:186-190) always uses NetworkUtil::GetLocalAddress6() with no escape hatch — fine for a host with a plain global address, but it leaves no answer for NAT66/prefix translation, and it will register whatever temporary/privacy address happens to be selected at the time, which then rotates.

Also minor: the // Allow IPv4 only for communicating with Directories comment still sits directly above all three changed ParseNetworkAddress calls (clientrpc.cpp:189, connectdlg.cpp:353, serverlist.cpp:1013).

Two things we checked that turned out to be fine, in case it saves a reviewer the trip: swapping ServerList[0].LHostAddr for ServerPublicIP at serverlist.cpp:1030 is equivalent (ServerList[0] is constructed at :215 with ServerPublicIP as its NLHAddr, and :640 only rewrites LHostAddr for other entries), and the serverlist.h bEnableIPv6 → bIPv6Available rename just aligns the declaration with the definition already at serverlist.cpp:87.

Just to note here:
I've closed jamulussoftware/jamuluswebsite#1027 as there is more IPv6 work due for Release 4.0.0. This part was missed from 3.12.0 and needs to be picked up.

Another sidenote from some somewhat unrelated AI review, have a look at IsPrivateNetworkIP() in util.cpp. It might miss IPv4-mapped IPv6 addresses.

| util.cpp:1121-1140 | IsPrivateNetworkIP misses IPv4-mapped IPv6 (::ffff:a.b.c.d classed public) and RFC5735 link-local 169.254/16 | Affects directory LAN classification decisions (serverlist.cpp:584,695,722) — wrong list fields handed out, no memory impact. Note: open PR #3809 (IPv6 directories) restructures these call sites (HostAddr→HostAddr4) without changing IsPrivateNetworkIP semantics — gap persists and the listed line refs will shift when it merges |

🤖 AI: Checked: IsPrivateNetworkIP does miss ::ffff: and 169.254/16 (Qt 5.15), but main and #3893 both set IPV6_V6ONLY, and on the wire a v4-mapped sender arrives on the AF_INET socket as plain IPv4 — so only a parsed address string can reach it with one.

sequenceDiagram
  participant JSON-RPC client
  participant serverrpc
  participant CServer
  participant ServerListManager
  JSON-RPC client->>serverrpc: Call jamulusdirectory/getServerList
  serverrpc->>CServer: Request directory server list
  CServer->>ServerListManager: GetDirectoryServerList
  ServerListManager-->>CServer: Return registered servers
  CServer-->>serverrpc: Return retrieval result
  serverrpc-->>JSON-RPC client: Return numservers and servers

• Fix all pre-merge checks with AI

_{Comment @coderabbitai help to get the list of available commands.}

🤖 AI: Two items: one on the interaction with #3893, one on CodeRabbit's three inline findings (wire format, persistence, keep-alive).

The #3893 interaction. Now that #3893 has merged, IsIPv6Available() false is reachable in a running server, and both gates this branch adds read it — serverlist.cpp:1015 and clientrpc.cpp:193.

Two binaries from this branch at 1d0a3651, identical except for socket.cpp/socket.h taken from #3893. Given --directoryaddress "[::1]:22400" and a --serverbindip6 address not on the host: this branch alone exits at startup with "Cannot bind the socket"; with #3893's socket code the server stays up, keeps only its IPv4 socket, and registration ends at Bad address. So that failure moves from "does not start" to "runs, unregistered". A directory-address misconfiguration that used to block startup outright now degrades silently: the server stays up, and the only signal is Bad address in the log.

With IPv6 healthy both builds register over IPv6 — Requested to register entry for [::1]:22401 in the directory log — so the path itself works.

The CodeRabbit findings. All three are about places that read HostAddr4; the miss is where its IPv4 sibling gets written. Since IndexOf matches by family, an IPv6 server's refresh reaches the update branch of Append for the first time, and that branch assigns LHostAddr4 = LInetAddr whatever the family, while the constructor used on first registration picks the field by protocol.

Measured at d0c74d10, headless build, directory on localhost:22500, one server registering to [::1]:22500 from port 22501. Registered once, directory stopped: the persisted line is ;;UzY=;;0;10;0 — the persistence finding's two empty address fields, true for exactly one registration. Same run with the server SIGKILLed (no unregister) and restarted on the same port: ;[::1]:22501;UzY=;;0;10;0 — the IPv6 address in the IPv4 internal-address column.

On the keep-alive timer: across one 59 s tick with that IPv6 entry present, the directory's only sendto was the registration response to [::1]:22501. No keep-alive left the socket, and nothing was logged.